libxl: update flex output files

libxl: update flex output files

Libxl ships output files from flex (libxlu_*_l.{c,h}). We use the flex
shipped in Debian to generate those files. Debian just patched their
flex (DSA 3653-1) to fix CVE-2016-6354, which is a buffer overrun bug.

Note that libxl is _NOT_ vulnerable to that CVE. See below for Ian's
analysis to security@xen.

It would still be nice that we update our shipped flex output files to
avoid confusion.

===QUOTE===

The bug is that with input >16K[1] flex would usually fail to resize
the input buffer, and then overrun it.

I have read the code in libxlu_cfg_l.c to try to understand the
implications for libxl.

AFAICT
 - libxl always does config file reading _from the file_ itself, and
   provides flex with a string or buffer.
 - so we always call whatever_yy_scan_bytes, not any other flex setup
   function to set up a `buffer' (as flex calls it)
 - yy_scan_bytes calls yy_scan_buffer to set up the buffer
 - yy_scan_buffer sets b->yy_fill_buffer
 - The effect of this is that yy_get_next_buffer will always
   return early, rather than continuing on to the vulnerable code.

So I think libxl is not vulnerable, regardless of the contents of the
configuration file.

[1] the default buffer size, or whatever other buffer size is
configured (but we don't change it)

===ENDQUOTE===

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>